Wayfinding

The Harvard Innovation Labs serves hundreds of student founders each semester across programs ranging from early-stage ideation to venture-backed acceleration.

With a diverse portfolio of programs, events, workshops, and advising resources, the i-lab faces a consistent challenge: 

founders don't know where to start.

This case study documents the end-to-end design and development of the i-lab Program Finder — a personalized wayfinding system that routes founders to the right programs and resources based on who they are, what they're building, and how much they can commit. The project spanned strategic program design, information architecture, content operations, and full front-end development — built and owned by a single staff member.

The Problem

Every semester, new i-lab members arrive with the same unspoken question: where do I begin?

The i-lab's answer to that question was inconsistent by design. A founder's starting point depended entirely on whether they found the right staff member to ask, attended the right orientation event, or happened to hear about the right program at the right time. For founders who were less networked, less confident, or simply less lucky, the result was drift — a summer of potential that never found its container.

The problem had three layers:

It didn't scale. The manual intake conversation — the one where a staff member asks a few questions and points a founder somewhere — was happening informally, repeatedly, and inconsistently. Every good starting-point conversation required a person.

It wasn't equitable. The quality of a founder's start at the i-lab was correlated with their ability to navigate an institution, not with the merit of their idea or the ambition of their goals.

It left program gaps invisible. Without a structured model for routing founders, there was no systematic way to identify which types of founders had no clear path — and therefore no clear way to design programs to fill those gaps.

The Approach

Rather than designing a solution first, the work began with a design question: 

What are the actual questions we ask a founder when we're trying to figure out where to point them?

This reframe was intentional. The goal wasn't to build a quiz — it was to make the implicit intake conversation explicit, structured, and reproducible. The quiz became the artifact of that thinking, not the starting point.

Mapping The Variables

The first step was identifying which variables actually changed a recommendation. Through structured reflection on how staff informally routed founders, four meaningful inputs emerged: Stage — where the founder is in their journeyGoal — what they want out of the semesterTime commitment — how much they can realistically giveSector — what space they're building in

A fifth variable — format preference — was added to address the reality that not all founders are in Cambridge, and not all programs are in-person.

Critically, these variables were not equal. Stage, goal, and time combine through a scoring model to produce a persona— a stable archetype that shapes the entire results experience. Sector modifies what appears within that persona but never changes the persona itself. This two-dimensional model — persona plus sector — became the conceptual foundation for the entire system.

Building The Results Logic

With personas defined, the next challenge was designing what each persona actually sees. This required a three-layer architecture: 

Layer 1 — Three Steps (left column) The most important output. Three specific, ordered actions for this founder right now. Built as a lookup table where each row answers: "For this persona, in this sector, at this step number — what should they do?" Sector-specific rows override a default fallback, which overrides universal rows. This allows the system to give a Life Sci founder a meaningfully different step 1 than a General founder, while sharing steps 2 and 3.

Layer 2 — Events (right column) Current semester events filtered by persona and sector tags, sorted by format preference. Each event carries a tag array — a subscription list that declares which founders it is relevant to. Adding a new event to the system requires only adding a new object with the right tags.

Layer 3 — Office Hours (bottom) Drop-ins and advising sessions filtered by persona, giving every founder a human touchpoint appropriate to their stage and needs.

The Build

The system was built as a standalone front-end application — no backend, no database, no authentication. Two files do all the work.

founder_xp_generator.html contains the quiz interface, scoring algorithm, and results renderer. It is designed to be stable — the logic inside it changes only if the program model itself changes.

ilab-data.js contains all content — links, events, office hours, step recommendations, and persona copy. It is designed to be edited — this is the only file that needs to be touched each semester.

This separation was a deliberate architectural decision. The quiz logic is durable. The content is perishable. Keeping them in separate files means a staff member can update the entire system for a new semester without touching the logic layer.

Key Design Decisions

Semester-swappable links. Every signup URL in the system lives in a single named table at the top of ilab-data.js. Updating a link for a new semester means finding one line and changing one value.

Active flag on all content. Events and office hours can be hidden without deleting them by setting active: false. This preserves historical data while keeping results clean.

Format mismatch notes. If a recommended program doesn't match a founder's format preference, the system flags it rather than hiding it. Hiding it would create gaps in recommendations. Flagging it gives founders the information they need to make a decision.

No program directory. A conscious decision was made to surface only what is directly relevant — maximum four events, three steps, and a handful of office hours. The goal is a starting point, not a catalog.

Supporting Infrastructure

Alongside the quiz itself, a full operational infrastructure was built to support long-term maintainability:

Google Sheets database — a four-tab spreadsheet (Links, Events, Office Hours, Steps) that serves as the human-readable editing interface. Staff update the sheet, then mirror changes to ilab-data.js.

Spreadsheet README — full documentation of every column, every valid value, and every rule. Written for a non-technical staff member who has never seen the system before.

Decision logic and update guide — a standalone HTML page that visually documents how the routing logic works, how personas are scored, how tags control event surfacing, and exactly where to go for every type of update. Built as a reference tool for whoever maintains the system going forward.

Talking points and presentation materials — a structured summary of the system for communicating its value to program leadership, including a soft presentation script designed for an innovation-oriented audience.

Reflection

The Program Finder started as a practical problem: founders don't know where to start and we can't have a manual conversation with all of them. It ended as something more interesting — a structured model of how the i-lab thinks about founders, made visible and editable. 

The most valuable thing this project produced is not the quiz. It is the act of making implicit institutional knowledge explicit. The six personas, the sector matrix, the step recommendations, the gap map — these existed in the heads of experienced staff members before this project began. They were just never written down in a form that could be tested, shared, updated, or used to ask hard questions about what we're building and for whom.

That is what wayfinding infrastructure actually does. It doesn't just help founders find their way. It forces the institution to decide what the ways are.

Built by a single staff member at the Harvard Innovation Labs, Summer 2026.Full codebase available at abarry25.github.io/summer_reference